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REAL PARTY IN INTEREST 



The present application is wholly owned by Bigband Networks, Inc. of Redwood 
city, California. 

RELATED APPEALS AND INTERFERENCES 

Appellant is unaware of other appeals or interferences which will directly affect, be 
directly affected by, or have a bearing on the Board's decision in this appeal. 

STATUS OF CLAIMS 

Claims 1, 3-9 and 11-28 are pending. 

Claims 1, 3-9 and 11-28 have been rejected. 

This application was filed on 10/30/2003, and included claims 1-19. 

On August 29 2007 a Non-Final Office Action was mailed and rejected all claims. 

On July 18 2008 a response was filed, claims 1, 3, 9, 11, 12, 16, 17, 19 were amended 
and claims 20-27 were added. 

On March 12 2009 a Final Office Action was mailed and rejected all claims. 

On April 2 2009 a request for continued examination (RCE) was filed and claims 1, 4, 
9, 16 and 19 were amended. 

On May 25 2009 a Non-Final Office Action was mailed and rejected all claims. 

On August 26 2009 a response was filed, claims 1, 9 and 19 were amended and claims 
2 and 10 were cancelled. 

On December 8 2009 a Non Final Office Action was mailed and rejected all claims. 

On April 7 2010 a response was filed. 

On June 29 2010 a Final Office Action was mailed and rejected all claims. 
On September 7 2009 a request for continued examination (RCE) was filed and 
claims 1, 9 and 19 were amended. 

On November 10 2010 a Non Final Office Action was mailed and rejected all claims. 



Page 4 

On March 18 2010 a response was filed, claims 1, 3, 5-6, 8, 11-14 and 16-18 have 
been amended and new claim 28 was added. 

On May 9 2011 a Final Office Action was mailed by the United States Patent and 
Trademark Office. All claims were rejected. 

Claims 1, 3-9, 1 1-21, 23-25 and 27-28 stand rejected under 35 U.S. C. § 103(a), as 
being unpatentable over Dygart (US patent 6954469) in view of Weaver (US patent 
6119154.) 

The rejection of claims 1, 3, 5, 6, 8, 9, 11, 13, 14, 16, 17, 18 and 19 is being appealed. 

STATUS OF AMENDMENTS 

This application was filed on 10/30/2003, and included claims 1-19. 

On July 18 2008 a response was filed, claims 1, 3, 9, 11, 12, 16, 17, 19 were amended 
and claims 20-27 were added. 

On April 2 2009 a request for continued examination (RCE) was filed and claims 1, 4, 
9, 16 and 19 were amended. 

On August 26 2009 a response was filed, claims 1, 9 and 19 were amended and claims 
2 and 10 were cancelled. 

On September 7 2009 a request for continued examination (RCE) was filed and 
claims 1, 9 and 19 were amended. 

On March 18 2010 a response was filed, claims 1, 3, 5-6, 8, 11-14 and 16-18 have 
been amended and new claim 28 was added. 

All amendments were entered. 

The claims appendix reflects the amendments entered by the examiner. 
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SUMMARY OF CLAIMED SUBJECT MATTER 

There is a growing need to provide efficient manners for providing live media streams 
and non-live media streams to users. 

The current application addresses a bottleneck between the video pump and a server 
that provides to the video pump a live stream and reduces the load over that network by 
providing only once a live stream to the video pump that in turn provides the live stream to 
multiple users (page 10, lines 1-30). 

The current application simplifies the generation and provision of trick media streams 
by using intra-coded frames and duplicating frames and allowing an alteration of timing 
information of these frames. 

Claim 1 (page 5, lines 5-7; page 7, lines 11-21; page 8, lines 10-26; page 13 lines 1- 

10; figures 2C, 2D, 3A and 4) reads as follows: 

A method for providing media streams, the method comprising the steps of: receiving 
live media streams at a first path, wherein the first path comprises a video pump coupled to a 
data acquisition unit; providing a live media stream from the first path to a client, in 
response to a request to provide the live media stream to the client; retrieving media related 
information that comprises data structures that assist in constructing non-live media streams; 
online generating by the video pump, in response to a request to receive a trick play media 
stream, a non-live media stream, by utilizing the media related information, wherein the 
generating comprises fetching intra-coded frames from locations that are pointed to at the 
media related information, and altering timing information of the intra-coded frames and of 
duplicating frames; and providing the non-live media stream from a second path to the client, 
wherein the second path comprises the video pump and a media server being coupled to each 
other by a network link that differs from a network link of the first path. 

Claim 3 (page 10, lines 8-26) reads as follows: 

The method of claim 1 comprising providing the live media stream to multiple users 
wherein the live media stream reaches the video pump only once. 

Claim 5 (page 12, lines 27-35, page 13, lines 11-26) reads as follows: 

The method of claim 1 wherein the data structures comprise an indexing file that 
comprises a duplicating frame and locations of the intra-coded frames. 

Claim 6 (figures 2C and 2D) reads as follows: 



Page 6 



The method of claim 1 wherein the non-live media stream is a trick mode media stream 
and wherein the non-live media stream consists essentially of the intra-coded frames and the 
duplicating frames. 

Claim 8 (Page 13, lines 27-30) reads as follows: 

The method of claim 1 wherein an amount of duplicating frames to be transmitted 
between each pair of intra-coded frames determines a presentation rate of the non-live media 
stream. 

Claim 9 (page 5, lines 1-31; page 7, lines 11-21; page 8, lines 10-26; page 10, lines 7- 
30, page 13 lines 1-10; figures 2C, 2D, 3A and 4) reads as follows: 

A system for providing media streams, the system comprising: 
a first path comprising a video pump coupled to a data acquisition unit; wherein the first 
path is utilized for receiving live media streams and for providing a live media stream to a 
client, in response to a request to provide ihe live media stream to the client; and 
a second path comprising the video pump and a media server being coupled to each other by 
a network link that differs from a network link of the first path; wherein the second path is 
operable to retrieve media related inforinaiioii that comprises data structures that assist in 
constructing non-live media streams; to online generate at least a portion of a non-live media 
stream in response to a request to provide the non-live media stream to the client, by utilizing 
the media related information, wherein the generating comprises fetching intra-coded frames 
from locations that are pointed to at the media related information, and altering timing 
information of the intra-coded frames and of duplicating frames; and to provide the non-live 
media stream to the client, in response to the request to provide the non-live media stream to 
the client. 

Claim 11 (page 10, lines 8-26) reads as follows: 

The system of claim 9 wherein the video pump is arranged to provide the live media 
stream to multiple users wherein the live media stream reaches the video pump only once. 

Claim 13 (page 12, lines 27-35, page 13, lines 11-26) reads as follows: 

The system of claim 9 wherein the data structures comprise an indexing file that 
comprises a duplicating frame and locations of the intra-coded frames. 

Claim 14 (figures 2C and 2D) reads as follows: 

The system of claim 9 wherein and wherein the non-live media stream consists 
essentially of the intra-coded frames and the duplicating frames. 

Claim 16 (page 5, lines 1-31; page 7, lines 11-21; page 8, lines 10-26; page 10, lines 

7-30, page 13 lines 1-10; figures 2C, 2D, 3 A and 4) reads as follows: 
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A system for providing media streams, the system comprising: an acquisition unit 
coupled to a media source; a media storage and management entity; a video pump interface, 
coupled to the output of the acquisition unit via a first path, to the media storage and 
management entity via a second path and to a command channel, the video pump interface is 
operable to receive instructions/ requests from an end-user and accordingly to determine 
whether to feed the video pump with live stream media from the acquisition unit via the first 
path or to initiate a data fetch sequence for fetching data stored in the media storage and 
management entity, via the second path, in case where trick modes are required; wherein the 
second path comprises a network link that differs from a network link of the first path; and 
a video pump that is operable to determine which data to fetch from the media storage and 
management entity and when to transmit it according to MPEG timing; wherein the video 
pump is arranged to provide the live media stream to multiple users wherein the live media 
stream reaches the video pump only once; 

wherein the media storage and management entity is adapted to generate at least a portion of 
a non-live media stream in response to a request to provide the non-live media stream to a 

client. 

Claim 17 (page 5, lines 1-31; page 7, lines 11-21; page 8, lines 10-26; page 10, lines 
7-30, page 13 lines 1-10; figures 2C, 2D, 3 A and 4) reads as follows: 

The system of claim 16 wherein the video pump is operable to fetch selected portions 
of the data stored at the media storage and management entity, wherein video pump is 
arranged to fetch selected portions based on an indexing file that comprises a duplicating 
frame and locations of the intra-coded frames . 

Claim 18 (page 13, lines 27-30; figures 2C and 2D) reads as follows: 

The system of claim 16 wherein an amount of duplicating frames to be transmitted 
between each pair of intra-coded frames determines a presentation rate of the non-live media 
stream. 

Claim 19 (page 5, lines 1-31; page 7, lines 11-21; page 8, lines 10-26; page 10, lines 
7-30, page 13 lines 1-10; figures 2C, 2D, 3 A and 4) reads as follows: 

A non-transitory computer readable medium having code embodied therein for 
causing an electronic device to perform the steps of: receiving live media streams at a first 
path, wherein the first path comprises a video pump coupled to a data acquisition unit; 
providing a live media stream from the first path to a client, in response to a request to 
provide the live media stream to the client; retrieving media related information that 
comprises data structures that assist in constructing non-live media streams; online 
generating by the video pump, in response to a request to receive a trick play media stream, a 
non-live media stream, by utilizing the media related information, wherein the generating 
comprises fetching intra-coded frames from locations that are pointed to at the media related 
information, and altering timing information of the intra-coded frames and of duplicating 
frames; and providing the non-live media stream from a second path to the client, wherein 
the second path comprises the video pump and a media server being coupled to each other by 
a network link that differs from a network link of the first path. 
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GROUNDS FOR REJECTION TO BE REVIEWED ON APPEAL 

1) Are claims 1, 9 and 19 patentable under 35 U.S.C. §103(a), over Dygart in view of 
Weaver? 

2) Are claims 3, 11 and 16 patentable under 35 U.S.C. §103(a), over Dygart in view of 
Weaver? 

3) Are claims 5, 13 and 17 patentable under 35 U.S.C. §103(a), over Dygart in view of 

Weaver? 

4) Are claims 6 and 14 patentable under 35 U.S.C. §103(a), over Dygart in view of 
Weaver? 

5) Are claims 8 and 18 patentable under 35 U.S.C. §103(a), over Dygart in view of 
Weaver? 
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ARGUMENTS FOR GROUND 1 

Claims 1. 9 and 19 
Dygart 

The Appellants argue that Dygart teaches of a system that includes a video pump that 
may stream recorded video from storage (abstract). The video pump does not stream live 
video but rather non-live video recorded at a storage device (Abstract; column 3, lines 49-61). 

It is noted that the only reference to live streaming of Dygart is made in the 
background section of Dygart - and in order to distinguish between streaming live video and 
streaming recorded video from storage (column 1, lines 39-47). 

Dygart does not teach or suggest duplicating frames. Dygart merely refers to frames 
in relation to bit rate consttaints or size consttaints alone (see for example column 1, lines 48- 
50; column 2, lines 45-65; column5, lines 25-35). 

Thus- Dygart does not teach or suggest "receiving live media streams at a first path, 
wherein the first path comprises a video pump coupled to a data acquisition uni t: providing a 
live media stream fi-om the first path to a client , in response to a request to provide the live 
media stream to the client" - as recited in claim 1. 

In addition - The Examiner admitted that Dygart does explicitly discloses "generating 
comprises fetching intra-coded fi-amesfrom locations that are pointed to at the media related 
information, and altering timing information of the intra-coded frames an d of duplicating 
frames " - as recited in claim 1. 

Accordingly - Dygart does not teach or suggest all the limitations of claim 1. 

Weaver 

The Examiner argued that Weaver teaches of "generating comprises fetching intra- 
coded frames from locations that are pointed to at the media related information, and 
altering timing information of the intra-coded frames an d of duplicating frames". 

The Examiner argues that "duplicating frames" appear when a request for fast forward 
and fast rewind is send and without duplicating frames users will be unable to read anything 
during fast forward and fast rewind. 
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The appellants argue that Weaver does not teach or duplicating frames, that the 
statement of the examiner about the presence of duplicating frames in fast forward and fast 
backward is not based upon Weaver and is a mere presumption raised by the Examiner 
without proper basis. 

Weaver teaches of various specific types of packets and data such as prefix data and 
padding packets but both differ from duplicating frames. Prefix data merely includes 
appropriate header information that is transmitted by the video pump prior to transmitting 
data from the new position (column 14, lines 21-26). Padding packets are non- video packets 
that are added to video packets to comply with transport packet requirements. See, for 
example, box 255 of figure 2A and Table 3, column 9: "# OF NON-VIDEO PACKETS The 
number of non-video packets 222 (i.e. audio packets, padding packets, control packets and 
timing packets) that are located within the picture packet for frame "F"'. 

Weaver teaches of performing fast forward and fast rewind by skipping some frames 
of the original (Stored) video stream but does not teach or suggest duplicating frames (see, 
for example, column 1, lines 45- 58 and column 1 1 , lines 18-27): 

Various approaches have been developed lo provide non-sequential playback of 
digital video data. With respect to digital video data, non-sequential playback refers to any 
playback operation that does not play all of the encoded frames in the exact order in the 
sequence in which they were encoded. For example, jump ahead and fast forward operations 
are non-sequential in that some frames are skipped . Rewind operations at any speed are non- 
sequential in that during a rewind operation, frames are not played in the sequence in which 
they are encoded. 

During normal playback operations, there is sufficient time to perform the disk 
accesses required to read an entire section while the data from the previous section is being 
transmitted in the MPEG data stream. However, during fast forward and fast rewind 
operations, less than all of the data in any .section will be sent in the MPEG data stream . 
Because less data is sent, the transmission of the data will take less time. Consequently, less 
time will be available to read and process the subsequent section. 

For example, assume that only one frame X from section 350 was selected for display 
during a fast forward operation. During the time it takes to transmit the segment for frame X, 
the data for the next selected frame Y is read and processed. Assume that the next frame Y is 
located in section 352. If the MPEG file is read and processed on a section by section basis 
(required for RAID), then all of the blocks in section 352 are read and processed during the 
transmission of the single frame X. Even if it were possible to read and process all of the 
blocks in section 352 in the allotted time, it may still be undesirable to do so because of the 
resources that would be consumed in performing the requisite disk accesses. 
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In light of the foregoing, video pump 120 does not use RAID during fast forward and 
fast rewind operations. Rather, video pump 120 reads, processes and transmits only the data 
indicated in the commands it receives from the stream server 118. Thus, in the example given 
above, only the frame data for frame Y would be read an d processed during the transmission 
of the segment for frame X . By bypassing RAID during fast forward and fast rewind 
operations, disk bandwidth remains at the same level or below that used during normal 
playback operations. 

The appellants will argue that it is known in the art that non- sequential retrieving of 
frames consists of retrieving only intra-coded frames (as they can be independently 
decodable) and that the fast forward and fast backward streams of Weaver includes only 
intra-coded frames - and that Weaver does not include fetching intra-coded frames from 
locations that are pointed to at the media related information, and altering timing 
information of the intra-coded frames an d of duplicating frames . 

Accordingly - Weaver does not teach or suggest all the limitations of claim 1. 

Conclusion 

Neither one of Dygart or Weaver, alone or in cousin, teaches all the features of claim 
1 and for that reason alone the 35 U.S.C. § 103(a) rejection of claim 1 is traversed and claim 
1 should be allowed. 

Claims 3-8, 20-23 and 28 depend, directly or indirectly, on claim 1 and include of all 
of its features. For this reason alone the 35 U.S.C. § 103(a) rejection of claims 3-8, 20-23 and 
28 is traversed and claims 3-8, 20-23 and 28 should be allowed. 

Claim 9 differs from claim 1 but the arguments applied to the rejection of claim 1 
should be applied to the rejection of claim 9. Thus - Neither one of Dygart or Weaver, alone 
or in cousin, teaches all the features of claim 9 and for that reason alone the 35 U.S.C. § 
103(a) rejection of claim 9 is traversed and claim 9 should be allowed. 

Claims 11-15 and 24-25 depend, directly or indirectly, on claim 9 and include of all of 
its features. For this reason alone the 35 U.S.C. § 103(a) rejection of claims 1 1-15 and 24-25 
is traversed and claims 11-15 and 24-25 should be allowed. 

Claim 19 differs from claim 1 but the arguments applied to the rejection of claim 1 
should be applied to the rejection of claim 19. Thus - Neither one of Dygart or Weaver, alone 
or in cousin, teaches all the features of claim 19 and for that reason alone the 35 U.S.C. § 
103(a) rejection of claim 19 is traversed and claim 19 should be allowed. 
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ARGUMENTS FOR GROUND 2 

Claims 3. 11 and 16 

Neither one of Dygart or Weaver, alone or in cousin, teaches of " providing the live media 
stream to multiple users wherein the live media stream reaches the video pump only once " 
as recited in claim 3. 

The current application addresses a bottleneck between the video pump and a server 
that provides to the video pump a live stream and reduces the load over that network by 

providing only once a live stream to the video pump that in turn provides the live stream to 
multiple users (paragraph [0038] - [0040] of the current application). 

Dygart does not teach or suggest such limitation. It teaches of a video pump that can 
access a RAID array or a DVD jukebox - and retrieve stored (non-live) data for each channel 
at a specified rate (column 7, lines 5-8). Furthermore, Dygart does not teach or suggest live 
media but rather teaches of providing recorded signals for playback (Abstract; column 5, 
lines 43-47 and column 10, lines 60-65). Furthermore - the only reference to live streaming of 
Dygart is made in the background section of Dygart - and in order to distinguish between 
streaming live video and streaming recorded video from storage (column 1, lines 39-47). 

Weaver does not discuss multiple requests from different clients to receive multiple 
live streams. 

Therefore - neither one of Dygart or Weaver, alone or in cousin, teaches all the 
features of claims 3 and for that reason alone the 35 U.S.C. § 103(a) rejection of claim 3 is 
traversed and claim 3 should be allowed. 

Claim 1 1 differs from claim 3 but the arguments applied to the rejection of claim 3 
should be applied to the rejection of claim 11. Thus - Neither one of Dygart or Weaver, alone 
or in cousin, teaches all the features of claim 11 and for that reason alone the 35 U.S.C. § 

103(a) rejection of claim 11 is traversed and claim 11 should be allowed. 

Claim 16 differs from claim 3 but the arguments applied to the rejection of claim 3 
should be applied to the rejection of claim 16. Thus - Neither one of Dygart or Weaver, alone 
or in cousin, teaches all the features of claim 16 and for that reason alone the 35 U.S.C. § 
103(a) rejection of claim 16 is traversed and claim 16 should be allowed. 
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ARGUMENTS FOR GROUND 3 

Claims 5. 13 and 17 

Neither one of Dygarl or VVcaxcr. alone or in cousin, leaches of " an indexing file that 
comprises a duplicating frame and locations of the intra-coded frames -" - as recited in claims 
5, 13 and 17. 

The current application provides a highly efficient retrieval scheme that provides an 
indexing file that includes a (concise) duplicating frame and location of intra-coded frames. 
This indexing fUe reduces the amount of data retrievals as a trick play stream can be 
generated by fetching the indexing file and intra-coded frames, without fetching additional 

duplicating frames (as they are included in the indexing file itself). 

Dygart does not teach of an indexing frame and in general does not discuss how the 
video pump performs trick plays (Column 6, lines 6-19). 

Weaver teaches of a complete separation between video files and tag data (figure 1, 
column 6, lines 5-13 and 17-40, column 6 line 55 - column 7, line 60 "EXEMPLARY MPEG 
FILE", and column 7, line 70 - column 10, line 40 "EXEMPLARY TAG FILE"). Weaver 
even suggests delaying the provision of control information (including tag data) to an MDS 

server to ensure that the video files referred to by the video files already exits (column 6, 
lines 40-53). The tag file of Weaver includes only metadata relating to the video file but does 
not include a duplicating frame (column 7, line 70 - column 10, line 40 "EXEMPLARY TAG 
FILE"). Weaver does not even discuss duplicating frames. 

Therefore - neither one of Dygart or Weaver, alone or in cousin, teaches all the 
features of claims 5, 13 and 17 and for that reason alone the 35 U.S.C. § 103(a) rejection of 
claims 5, 13 and 17 is ttaversed and claims 5, 13 and 17 should be allowed. 
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ARGUMENTS FOR GROUND 4 

Claims 6 and 14 

Neither one of Dygart or Weaver, alone or in cousin, teaches of " the non-live media 
stream consist essentially of the intra-coded frames and the duplicating frames " - as recited 
in claims 6 and 14. 

The current application provides a non-live media stream that consists essentially of 
intra-coded frames and duplicating frames. 

Neither one of Dygart and Weaver teaches or suggests of duplicating frames and 
especially does not teach or suggest of a non-live media stream that consists essentially of the 
intra-coded frames and the duplicating frames. 

Dygart does not discuss the content of its video streams. 

Weaver teaches a media stream that includes intra-codes frames as well as P-frames 
and B-frames - as illustrated by the FRAME TYPE field of column 8, lines 64-68. 

Therefore - neither one of Dygart or Weaver, alone or in cousin, teaches all the 
features of claims 6 and 14 and for that reason alone the 35 U.S.C. § 103(a) rejection of 
claims 6 and 14 is traversed and claims 6 and 14 should be allowed. 
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ARGUMENTS FOR GROUND 5 

Claims 8 and 18 

Neither one of Dygart or Weaver, alone or in cousin, teaches of " wherein an amount 
of duplicating frames to be transmitted between each pair of intra-coded frames determines a 
presentation rate of the non-live media stream " - as recited in claims 8 and 18. 

Neither one of Dygart and Weaver teaches or suggests of duplicating frames and 
especially does not teach or suggest of an amount of duplicating frames to be transmitted 
between each pair of intra-coded frames determines a presentation rate of the non-live media 
stream . 

Dygart does not discuss the content of its video streams. 

Weaver teaches a media stream that includes intra-codes frames as well as P-frames 
and B-frames - as illustrated by the FRAME TYPE field of column 8, lines 64-68. 

Therefore - neither one of Dygart or Weaver, alone or in cousin, teaches all the 
features of claims 8 and 18 and for that reason alone the 35 U.S.C. § 103(a) rejection of 
claims 8 and 18 is traversed and claims 8 and 18 should be allovi^ed. 



Conclusion 

In view of the foregoing amendments and remarks, AppeUies assert that the pending 
claims are allowable. Their favorable reconsideration and allowance is respectfiiUy 

requested. 

Should the Board of Appeal have any question or comment as to the form, content or 
entry of this Appeal Brief, the Board of Appeal is requested to contact the undersigned at the 
telephone number below. 
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CLAIMS APPENDIX 

1. (Previously Presented) A method for providing media streams, the method comprising 

the steps of: 

receiving live media streams at a first path, wherein the first path comprises a 
video pump coupled to a data acquisition unit; 

providing a live media stream from the first path to a client, in response to a 
request to provide the live media stream to the client; 

retrieving media related information that comprises data structures that assist in 
constructing non-live media streams; 

online generating by the video pump, in response to a request to receive a trick 
play media stream, a non-live media stream, by utilizing the media related 
information, vi^herein the generating comprises fetching intra-coded frames from 
locations that are pointed to at the media related information, and altering timing 
information of the intra-coded frames and of duplicating frames; and 

providing the non-live media stream from a second path to the client, vi^herein 
the second path comprises the video pump and a media server being coupled to each 
other by a network link that differs from a network link of the first path. 

2. (Canceled). 

3. (Previously Presented) The method of claim 1 comprising providing the live media 
stream to multiple users wherein the live media stream reaches the video pump only 

once. 

4. (Previously Presented) The method of claim 1 wherein the media related information 
comprises information indicative of a location of a stored media stream and wherein the 
generating of a non-live media stream fiirther comprises a determination of which 
frames of the stored media stream to fetch from the first path. 

5. (Previously Presented) The method of claim 1 wherein the data structures comprise an 
indexing file that comprises a duplicating frame and locations of the intra-coded 
frames. 
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6. (Previously Presented) The method of claim 1 wherein the non-live media stream is a 
trick mode media stream and wherein the non-live media stream consists essentially of 
the intra-coded frames and the duplicating frames. 

7. (Original) The method of claim 1 further comprising a step of providing a live media 
stream from the first path to a client, in response to a request to provide a slightly 

delayed media stream to the client. 

8. (Previously Presented) The method of claim 1 wherein an amount of duplicating frames 
to be transmitted between each pair of infra-coded frames determines a presentation 
rate of the non-live media stteam. 

9. (Previously Presented) A system for providing media sfreams, the system comprising: 

a first path comprising a video pump coupled to a data acquisition unit; wherein 
the first path is utilized for receiving live media sfreams and for providing a live 
media stream to a client, in response to a request to provide the live media sfream to 
the client; and 

a second path comprising the video pump and a media server being coupled to 
each other by a network link that differs from a network link of the ffrst path; 
wherein the second path is operable to retrieve media related information that 
comprises data structures that assist in constructing non-live media sfreams; to 
online generate at least a portion of a non-live media sfream in response to a request 
to provide the non-live media sfream to the client, by utilizing the media related 
information, wherein the generating comprises fetching infra-coded frames from 
locations that are pointed to at the media related information, and altering timing 
information of the intra-coded frames and of duplicating frames; and to provide the 
non-live media stream to the client, in response to the request to provide the non-live 
media stream to the client. 

10. (Canceled). 

11. (Previously Presented) The system of claim 9 wherein the video pump is arranged to 
provide the live media stream to multiple users wherein the live media stream reaches 
the video pump only once. 
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12. (Previously Presented) The system of claim 9 wherein the first path comprises the video 
pump 

13. (Previously Presented) The system of claim 9 wherein the data structures comprise an 
indexing file that comprises a duplicating frame and locations of the intra-coded 
frames. 

14. (Previously Presented) The system of claim 9 wherein and wherein the non-live media 
stream consists essentially of the intra-coded frames and the duplicating frames. 

15. (Original) The system of claim 9 wherein the first path is further operable to provide 
live media stteam, in response to a request to provide a slightly delayed media stteam 
to the client. 

16. (Previously Prcscnlcd) A system for providing media streams, the system comprising: 

an acquisition unit coupled to a media source; 
a media storage and management entity; 

a video pump interface, coupled to the output of the acquisition unit via a first 
path, to the media storage and management entity via a second path and to a 
command channel, the video pump interface is operable to receive instructions/ 
requests from an end-user and accordingly to determine whether to feed the video 
pump with live stream media from the acquisition unit via the first path or lo initiate 
a data fetch sequence for fetching data stored in the media storage and management 
entity, via the second path, in case where trick modes are required; wherein the 
second path comprises a network link that differs from a network link of the first 
path; and 

a video pump that is operable to determine which data to fetch from the media 
storage and management entity and when to ttansmit it according to MPEG timing; 
wherein the video pump is arranged to provide the live media stream to multiple 
users wherein the live media stream reaches the video pump only once; 

wherein the media storage and management entity is adapted to generate at least 
a portion of a non-live media stream in response to a request to provide the non-live 
media stream to a client. 
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17. (Previously Presented) The system of claim 16 wherein the video pump is operable to 
fetch selected portions of the data stored at the media storage and management entity, 
wherein video pump is arranged to fetch selected portions based on an indexing file that 
comprises a duplicating frame and locations of the intra-coded frames . 

18. (Previously Presented) The system of claim 16 wherein an amount of duplicating 
frames to be transmitted between each pair of intra-coded frames determines a 
presentation rate of the non-live media stream. 

19. (Previously Presented) A non-transitory computer readable medium having code 
embodied therein for causing an electronic device to perform the steps of: 

receiving live media streams at a first path, wherein the first path comprises a 
video pump coupled to a data acquisition unit; 

providing a live media stream from the first path to a client, in response to a 
request to provide the live media stream to the client; 

retrieving media related information that comprises data structures that assist in 
constructing non-live media streams; 

online generating by the video pump, in response to a request to receive a trick 
play media stream, a non-live media stream, by utilizing the media related 
information, wherein the generating comprises fetching intra-coded frames from 
locations that are pointed to at the media related information, and altering timing 
information of the intra-coded frames and of duplicating frames; and 

providing the non-live media stream from a second path to the client, wherein 
the second path comprises the video pump and a media server being coupled to each 
other by a network link that differs from a network link of the first path. 

20. (Previously Presented) The method of claim 1, wherein the generating comprises 
generating at least the portion of the non-live media stream by converting the live 
media stteam to provide at least the portion of the non-live media stteam. 

21. (Previously Presented) The method of claim 1, wherein the receiving further comprises 
receiving a live media stream from a first media source, and wherein the retrieving 
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comprises retrieving media related information from a second media source that is 
different from the first media source. 

22. (Previously Presented) The method of claim 3, fiirther comprising storing non-live 
media streams at the video pump, providing a first portion of the non-live media stream 
from the video pump to the client, and providing a second portion of the non-live media 
stream from the media server, vi^herein the generating comprises generating the second 
portion of the non-live media stream. 

23. (Previously Presented) The method of claim 8, wherein the converting comprises 
converting a live media stream to a non-live media stream that substantially includes 
intra coded frames of the live media stream and duplicating frames. 

24. (Previously Presented) The system of claim 9, vi^herein the second path is fiirther 
operable to generate at least the portion of the non-live media stream by converting the 

live media stream to provide at least the portion of the non-live media stream. 

25. (Previously Presented) The system of claim 9, wherein the first path is operable to 
receive a live media stream from a &st media source, and wherein the second path is 
further operable to retrieve media related information from a second media source that 
is different from the &st media source. 

26. (Previously Presented) The system of claim 16, wherein the video pump is further 
adapted to store non-live media streams, to provide a first portion of a non-live media 
stream that is stored at the video pump to the client, and to providing a second portion 
of the non-live media stream from the media storage and management entity, wherein 
the media storage and management entity is adapted to generate the second portion of 
the non-live media stteam. 

27. (Previously Presented) The system of claim 16, wherein the media storage and 
management entity is adapted to convert a live media stream to a non-live media stteam 
that substantially includes the intta coded frames of at least a portion of the live media 

stream, and duplicating frames. 

28. (Previously Presented) The method according to claim 1 wherein the first path comprises 

the video pump. 
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EVIDENCE APPENDIX 



There is no information needed to be presented in this appendix. 
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RELATED PROCEEDINGS APPENDIX 



There is no information needed to be presented in this appendix. 



